PCT/FROO/03193 

TRAITE DE ^bPERATION EN MATIERE BREVETS ^ 



Expediteur: le BUREAU INTERNATIONAL 



PCT 



NOTIFICATION DE LA RECEPTION DE 
L'EXEMPLAIRE ORIGINAL 

(regie 24.2.a) du PCT) 



Destinataire: 

CORLU, Bernard 
Bull S.A. 
PC58D20 

68, route de Versailles 
F-78434 Louveciennes Cedex 
FRANCE 



'•A, 



Date d'expedition Gour/mois/ann6e) 

17 janvier2001 (17.01.01) 


NOTIFICATION IMPORTANTE 


Reference du dossier du deposant ou du mandate ire 
PCT 3809/BC 


Demande internationate no 
PCT/FROO/03193 



II est notifid au deposant que le Bureau international a regu I'exennplaire original de la demande Internationale precis6e 
ci-aprfes. 

Nom(s) du ou des d6posants et de I'Etat ou des Etats pour lesquels ils sont d^posants: 

BULL CPS (pour tous les Etats designes sauf US) 
GOIRE, Christian etc. (pour US seulement) 

Date dud6p6t international 17 novembre 2000 (17.11.00) 

Date(s) de priority revendiqu6e(s) 17 novembre 1999 (17.1 1 .99) 

Date de reception de Texemplaire original 
par le Bureau international : 

Liste des offices designes : 



05 Janvier 2001 (05.01.01) 



EP :AT,BE,CH,CY,DE,DK,ES,FI,FR,GB,GRJEJT,LU,IVIC,NL,PT,SE,TR 
National :BR,CA,CN,JP,US 



ATTENTION 

Le d6posant doit soigneusement verifier les indications figurant dans la pr6sente notification. En cas de divergence entre ces 
indications et celles que contient la demande internationale, il doit aviser Imm6diatement le Bureau international. 
En outre, Tattention du d6posant est appel^e sur les renseignements donn6s dans I'annexe en ce qui concerne 



X 



les d6lais dans lesquels doit etre abord6e la phase nationale 
[ X[ la confirmation des designations faites par mesure de precaution 
I I les exigences relatives aux documents de priorite. 

Une copie de la pr6sente notification est envoyee a I'office r^cepteur et i Tadministration chargde de la recherche internationale. 





Fonctionnaire autoris6 j / ^1 


Bureau international de I'OMPI 




34, chemin des Colombettes 


KariidLuynh^ 


121 1 Gendve 20, Suiss 


n* de t6l6copieur (41-22) 740.14.35 


n* de telephone (41-22) 338.83^ 



Formulaire PCT/IB/301 (juillet 1998) 



003776070 



ANNEXE DU Fi 



d^PjLAIRE PCT/IB/301 



Dejnapde intemationale no 

PCT/FROO/03193 



RENSEIGNEMENTS CONCERNANT LES DELAIS DANS LESQUELS DOIT ETRE ABORDEE 

LA PHASE NATIONALE 

II est rappele au deposant qu'il dolt aborder la "phase natlonaie" aupres de chaoun des offices d6slgn§s indiqu6s sur la 
notification de la reception de I'exemplalre original (formulaire PCT/IB/301) en payant les taxes nationales et en remettant les 
traductions, telles qu'elles sont prescrites par les legislations nationales. 

Le delai d'acoomplissement de ces actes de procedure est de 20 MOIS a compter dela date de priorit6 ou, pour les Etate 
d6sign6s qui ont 6t6 6lus par le d6posant dans une demande d'exanr,en pr6llmina.re mternat.onal ou dans ""^.f "'^l^^^-^^' 
de 30 Mors i compter de la date de priority, i condition que cette 6lectionait 6te effectu6e avant '^'^P';f 'l"^,^.^^^^^^ 
compter de la date de priority. Certains offices d^signes (ou 6lus) ont fix6 des d6lais qui expirent au-de Id de 20 ou 30 mo.s d 
compter de la date de priorltS. D'autres offices accordent une prolongation des d6lais ou un d6la. de grace, dans certa.ns cas 
moyennant le paiement d'une taxe supplementaire. 

En plus de ces actes de procedure, le deposant devra dans certains cas satisfaire d d'autres exigences particulieres 
applicables dans certains offices. II apparent au diposant de veiller i remplir en temps voulu les °°"^"'°"f;^^"'*,f^P°";,,^ 
rouvetlure de la phase natlonaie. La majorit6 des offices deslgn6s n'envoient pas de rappel i I'approche de la date l.mite pour 
aborder la phase nationals. 

Des infonnations detaill6es concernant les actes de procedure d accomplir pour aborder la 1 toutes 

chaque office d6sign6. les d^lais applicables et la possibilitfe d'obtenir une prolongatton des delais ou ^^la. de g;^^ ||*<:"t«/ 
autres conditions applicables figurent dans le volume II du Guide du dfeposant du PCT Les exigences '^"^^L 'IZ hI^^t 
demande d'examen prfeliminaire international sont exposfees dans le chapitre IX du volume I du Gu.de du deposant du POT. 

GR et ES sont devenues Ii6es par le chapitre II du PCT le 7 septembre 1 996 et le 6 ^eptembrel 997 respe«ivem^^^^^^^ 
peuvent done etre 6lues dans une demande d'examen pr6liminaire international ou dans une 6 ection " /^^^ '^J., 

septembre 1996 (ou i une date post6rieure) ou le 6 septembre 1997 (ou 3 une date post6neure). respeotivement, quelle que so.t 
la date de depot de la demande Internationale (voir le second paragraphe, ci-dessus). 

Veuillez noter que seul un d6posant qui est ressortissant d'un Etat contractant du PCT 116 par le chapitre II ou qui y a 
son domicile peut presenter une demande d'examen pr6liminaire international. 

CONFIRMATION DES DESIGNATIONS FAITES PAR MESURE DE PRECAUTION 

Seules les designations expresses faites dans la requ§te conformfement i la regie 4.9.a) figurent dans P^f^^nte 
notification. II est important de v6rifler si ces designations ont 6te faites correctement. Des ^^^.^i^"^^^^^^^^^ 
etre corrig6es lorsque des designations ont 6t6 faites par mesure de precaution en vertu de la r^gle 4.9 b). ^^^^^J^^'^^f"" 
a nsi faite peut Stre confirmee conformement aux dispositions de la rfegle 4.9.c) avant I'expiration d'un deia. de 1 5 mo.s a 
compter de la date de priorit6. En I'absence de confirmation, une designation faite par mesure de pr6cau ion sera <^on|'d«^f « 
comme retiree par le d6posant. 11 ne sera adress6 aucun rappel ni invitation. Pour confirmer une designation , .1 f.a"t d6poser une 
SSatlon precisant TEtat d6signe concem6 (avec Tindication de la forme de protection ou de traitement souha.t6e) et payer les 
taxes de designation et de confirmation. La confirmation doit parvenir d I'office r6cepteur dans le deiai de 15 mois. 

EXIGENCES RELATIVES AUX DOCUMENTS DE PRIORITE 

Pour les deposants qui n'ont pas encore satisfait aux exigences relatives aux documents de priorit6. 11 est rappeie ce qui 



suit. 



Lorsque la priorit6 d'une demande natlonaie, r6gionale ou intemationale anteneure est revendiqu6e, le «^6posant doit 
presente°une copie de cette demande ant6rieure, ce-tifiee conforme par I'admin.stration auprds de '«''';e''%«''«J,f f^^f 
f'document de priorit6"). d I'office recepteur (qui la transmettra au Bureau international) ou directement Bureau mte national, 
Lant"'Txpiration d'un d6lai de 16 mois d compter de la date de priorite, 6tant entendu que tout document de priorite peut etre 
prlsente a^ Bureau i^^^ avant la date de publication de la demande internationale. auquel cas ce document sera r6put6 

avoir ete recu par le Bureau international le dernier jour du d6lai de 16 mois (rdgle 17.1.a)). 

Lorsque le document de priorite est d61ivr6 par I'office recepteur, le d6posant peut, au lieu P^6/«"J«'"J;^^°fXr*' 
demander i I'office recepteur de le preparer et de le transmettre au Bureau internationaL La requete i cet effet doit Stre 
formuiee avant I'expiration du d6lai de 16 mois et peut etre soumise au paiement d une taxe (regie 17.1.b)). 

Si le document de priorite en question o'est pas foumi au Bureau international, ou si la demande adress6e d I'office r6cepteur 
de preparer et de transmettre le document de priorite n'a pas et6 faite (et la taxe correspondante acquittee, le <«s 6ch6ant) 
avant I'expiration du deiai applicable mentionn6 aux paragraphes precedents, tout Etat d6sign6 peut ne pas tenir compte 
de la revendication de priori°e; toutefois, aucun office design6 ne peut decider de ne pas tenir compte de la . 
priorite avant d'avoir donn6 au deposant la possibilite de remettre le document de pnorite dans un deia. ra.sonnable en I espece 

Lorsque plusieurs priorites sont revendiquees, la date de priorite d prendre en consideration aux fins du calcul du d61ai de 
16 mois est la date du depot de la demande la plus ancienne dont la priorit6 est revendiqu6e. 



Formulaire PCT/IB/301 (annexe) Ouillet 1998) 



003776070 



PCT/FROO/03193 

TRAITE DE OPERATION EN MATIERE BREVETS 



Expediteur : le BUREAU INTERNATIONAL 



PCT 

NOTIFICATION RELATIVE 
A LA PRESENTATION OU A LA TRANSMISSION 
DU DOCUMENT DE PRIORITE 

(instruction adnnmistrative 411 du PCT) 


Destinataire: 

CORLU, Bernard 

O , ,1 1 O A 

DUll o.A. 

PC58D20 

68, route de Versailles 

r-/0*+0'r LOUVCUlCl II ICO ^-»CUCA. 

FRANCE 


Date d'exp6dition (jour/mois/ann6e) 
17 janvier 2001 (17.01.01) 


Reference du dossier du deposant ou du mandataire 
PCT 3809/BC 


NOTIFICATION IMPORTANTE 


Demande internationale no 
PCT/FROO/03193 


Date du depot intert v ,r/mois/annee) 

17 novembre 20uo , . 1.00) 


Date de publication internationale Qour/mois/annee) 
Pas encore publiee 


Date de priority (jour/mois/annee) 

17 novembre 1999 (17.11.99) 


Deposant 

BULL CPS etc 



1 La date de reception (sauf lorsque les lettres "NR" figurent dans la colonne de droite) par le Bureau mternat.onal du ou des 
documents de pnorltfe correspoh-daht a la ou aux demandes 6num6rees ol-apr6s est notifl6e _au d6posant; Sauf md.catioa 
contraire conslstant en un ast6risque figurant k c6t6 d'une date de reception, ou les lettres NR , dans la colonne de droite, 
le document de priority en question a 6t6 pr6sent6 ou transmis au Bureau international d'une maniSre conforme a la 
rdgle 17.1.a) ou b). 

2. Ce formulaire met a jour et remplace toute notification relative 3 la presentation ou d la transmission du document de priorlt6 
qui a 6t6 envoySe pr6c§demment. 

3 Un ast6risqueC) figurant h oot6 d'une date de r6ception dans la colonne de droite signale un document de priority pr6sent6 
ou transmis au Bureau international mais de manldre non conforme a la r6gle 17.1.a) ou b). Dans ce cas, I attention du 
dfeposairt est appel6e sur la regie 17.1.c) qui stipule qu'aucun office d6sign6 ne peut decider de ne pas tenir compte de la 
revendication de priority avant d'avoir donn6 au deposant la possibilit6 de remettre le document de pnoriti dans un dfelai 
raisonnable en I'esp^ce. 

4 Les lettres "NR" figurant dans la colonne de droite signalent un document de prioritS que le Bureau international n'a pas 
recu ou que le d6posant n'a pas demand6 S I'office r6cepteur de preparer et de transmettre au Bureau international, 
conform6ment h la rdgle 17.1.a) ou b), respectivement. Dans ce cas, I'attention du dfiposant est appelte sur la ;^9'e ^/.-l-c) 
qui stipule qu'aucun office d6sign6 ne peut d6cider de ne pas tenir compte de la revendication de priorit6 avant d avoir donnfe 
au d6posant la possibllit6 de remettre le document de priorit6 dans un d^lai raisonnable en I'espece. 

Date de Driorit6 namanriB de orioritfe n* Pfiyp, office r^qional ou D^te de r^CgPtion dM 

^ 1^' V iv office r^ceoteur selon le PCT dQPMmgnt de priorit6 



17 nove 1999 (17.11.99) 99/14454 



FR 05 janv 2001 (05.01.01) 





Fonctionnaire autorls6: \ 






Bur au international de I'OMPI 




nrtf^Khuong 




34, ch min des Colombettes 


Karl HiL 




1211 Gendv 20,Suiss 








no de t6l6copieur (41-22) 740.14.35 


no de t6l6phone (41 -22) 338:«43p 







Formulaire PCT/IB/304 (juillet 1998) 



TRAITE DE ^DPERATION EN MATIERE BREVETS 



WO 01/37085 
PCT/FR 00/03 193 



5 ^ 



Expediteur: le BUREAU INTERNATIONAL 



PCT 



AVIS INFORMANT LE DEPOSANT DE LA 
COMMUNICATION DE LA DEMANDE 
INTERNATIONALE AUX OFFICES DESIGNES 

(regie 47.1.c), premiere phrase, du PCT) 



Date d'expedition (jour/mois/ann6e) 
25 mai 2001 (25.05.01) 



Destinataire: 

CORLU, Bernard 
Bull S.A. 
PC58D20 

68, route de Versailles 
F-78434 Louveciennes Cedex 
FRANCE 



Reference du dossier du d6posant ou du mandataire 
PCT 3809/BC 


AVIS IMPORTANT 


Demande Internationale no 
PCT/FROO/03193 


Date du depot international (jour/mo is/an nee) 
17 novembre 2000(17.11.00) 


Date de priorite (jour/mois/annee) 

17 novembre 1999 (17.11.99) 


Deposant 

BULL CPS etc 



1 II est notifid par la pr6sente qu'a la date Indiqu6e cl-dessus comme date d'expedition de cat avis, le Bureau international a 
communique, comme le prevoit I'article 20, la demande Internationale aux offices designes suivants: 

US 



Conform^ment a la rdgle 47.1. c), troisieme phrase, ces offices acceptent le present avis comme preuve determinante 
du fait que la communication de la demande Internationale a bien eu lieu a la date d'expedition indiqu6e plus haut, et le 
deposant n'est pas tenu de remettre de copie de la demande internationale a I ' office ou aux offices d6sign6s. ' 

2. Les offices designes suivants ont renonce d I'exigence selon laquelle cette communication doit etre effectuee ^ cette date: 

BR,CA,CN,EP,JP 



La communication sera effectuee seulement sur demande de ces offices. De plus, le deposant n'est pas tenu de remettre 
de copie de la demande internationale aux offices en question (regie 49.1)a-bis)). 

3. Le present avis est accompagne d'une copie de la demande internationale publiee par le Bureau international le 
25 mai 2001 (25.05.01) sous le num^ro WO 01/37085 

RAPPEL CONCERNANT LE CHAPITRE II (article 31.2)a) et regie 54.2) 

Si le deposant souhaite reporter I'ouverture de la phase nationale jusqu'd 30 mois (ou plus pour ce qui concerne certains 
offices) d compter de la date de priority, la demande d'examen pr^liminaire international doit etre pr6sent6eji 
{'administration comp6tente charg^e de I'examen pr6liminaire international avant I'expiration d un d6lai de 19 mois d 
compter de la date de priority. 

II appartient exclusivement au d6posant de veiller au respect du d6lai de 19 mois. 

II est h noter que seul un ddposant qui est ressortissant d'un Etat contractant du PCT \\6 par le chapitre II ou qui y a son 
domicile peut presenter une demande d'examen pr6liminaire international. • 

RAPPEL CONCERNANT L'OUVERTURE DE LA PHASE NATIONALE (article 22 ou 39.1)) 

Si le deposant souhaite que la demande internationale procdde en phase nationale, il doit, dans le delai de 20 mois ou 
de 30 mois, ou plus pour ce qui concerne certains offices, accomplir les actes mentionn6s dans ces dispositions aupr^s 
de chaque office d6sign6 ou ^lu. 

Pour d'autres informations importantes concernant les d6lais et les actes S accomplir pour I'ouverture de la phase 
nationale, voir I'annexe du formulaire PCT/IB/301 (Notification de la reception de I'exemplaire original) et le volume II 
du Guide du deposant du PCT. 





Fonctionnaire autoris6 


Bureau international de TOMPI 




34, chemin des Col mbettes 


J. Zahra 


1211 G nev 20^ Suisse 




no de t6l6copieur (41-22) 740.14.35 


no det6l6phone (41-22) 338.83.38 



Formulaire PCT/IB/308 (juillet 1996) 



4029374 



PCX 

REQUETE 



Le soussignd requiert que la pr6sente demande _ 
intemationale soit traitee conform^ment au Traitd de 
cooperation en mati^re de brevets. 



Reserve ^ r^^H-^cepteur 



Demande intemationaie n° 



Date du d^pot international 



>jom de r office r6ceptcur ct "Demande Internationale PCT" 



R6f6rence du dossier du ddposant ou du mandataire (facultatij) 
(12 caracteres au maximum) PCT 3809/BC 



I Cadre n^l TITRE DE L'lNVENTlON proc6d6 de chargement d'applications dans un systdme embarqu§ 
multi-application muni de ressources de traitement de donn6es, systeme embarqu6 correspondant, et p roced6 d'ex6cut.on 
1 d'une application d'un svst6me e mbaraufe corr 
Cadre n° II DEPOSANT 



Nom et adresse : (Nam iefamilie suivi du pre^^^^^^^ 
n 'est indique ci-dessous.) 



BULLCP8 

68, route de Versailles 
BP 45 

78430 LOUVECIENNES 
FRANCE 



□ Cette personne est aussi 
inventeur. 



n" dc t6l6phone 



n" de tdldcopieur 



{3"^) 1 3q fifi fi1 7fi 



n" de t^idimpnmeur 



(33) 1 39.66 . 61 . 73 



Mationalitd (nom de I'fetat) : 



FRANCE 



Domicile (nom de I'Etat) : 



FRAKin.F 



□ tous les Etats 
d6sign6s 

r«dre n' 111 AUTRE(S) DEPOSANT(S) OU (AUTRE(S)) INVENTEUR(S) 



Cctte personne est 
d6posant pour : 



i ^TTr^A^inn^ccaiif 1 1 les 6tats-Unis d'Am^rique I i les Eiats indiquis dans 

I?s"l«l-UMs'd-tequf □Uulemem U le cadre suppl^mentaire 



Nom et adresse : (Nom de familie i 
officielle complete. L adresse don 
radresse indiquee dans ce cadre i 
n'est indiqui ci-dessous.) 

Goire Christian 
8 allee du Mail 

78340 LES CLAYES SOUS BOIS 
FRANCE 



Nationality (nom de rfetal) : 



Cette personne est : 

I I d6posant seulement 

I d^posant el inventeur 

I I inventeur seulement 
(Si cette case est cochee. 
ne pas rempUr la suite.) 



Cette personne est 
diposant pour : 



FRANHF 



Domicile (nom de rfetat) : 



FRANCE 



□ tous les tials | 1 tous les tiats d6sign6s.sauf 
ddsignis l_J ICS Etats-Unisd-Am^nque 



Eles ttals-Unis d' Amdrique i 1 les Etats indiqu6s dans 
seulement | I le cadre suppldmentaire 



|~] D^aulres ddposants ou inventeurs sont Indiqufe sur une fcuille annexe 



..... ,v ^.^,nAT AIRE ou REPRfcSENTANT COMMUN; OU A DRESSE POUR LA CORRESPONDANCE 



I a personne dont V identity est donnde ci-dessous est/a 6t6 d6sign6e pour agir au nom du ou j-J niandataire Q repr^sentant 
des d6posants aupr6s des autorit^s intemationales compaentes,comme. ^ ^ . 



commun 



Nom el adresse 



(Nam de famille suivi du prenom: pour une personne morale, designation officielle 



BULL S.A 
CORLU Bernard 

PC58D20 / 68. route de Versailles 

F- 78434 LOUVECIENNES Cedex (FRANCE) 



n** de t6l6phone 

(33) 1 39.66.61 .76 



n* dc tdUcopieur 

(33) 1 39.66.61 .73 



n* de t4l6imprimeur 



CM 



Formulaire PCT/RO/101 (prcmifcrc fcuille) GuiHel 1998; ^impression janvier 2000) 



Voir les notes relatives au formulaire de regueie 



Feuille n" 



Suite du cadre n"* 111 AUTRE(S) DEPOSANT(S) OU (AUTRE(S)) INVENTEUR(S) 



5'/ aucun des sous-cadres suivants n 'est utilise, cette feuiiie ne doit pas itre incluse dans la requete. 


-Nom et adresse ' (Norn de famille suivi du prenom; pour une personne moraie, designation 
officieUe complete. L 'adresse doit comprendre le code postal et le nom du pays. Lepays de 
1 adresse indiquee dans ce cadre est I iLtat ou te aeposani a son aomiciie auLun uurnn^nK 
n 'est indique ci-dessous.) 

Billon Jean-Paul 

96 Uranus terrace 

SAN FRANCISCO, CA 94114 

USA 


Cette personne est : 

1 J dyposant seulement 

1 dyposant et inventeur 

1 1 inventeur seulement 
(Si cette case est cochee, 
ne pas remplir la suite.) 


Nationality (nom de i'Etat) : 

FRANCE 


Domicile (nom de I'Etat) : 

USA 


Cetle personne est | 1 touslcsfetats 1 1 tousles Etatsd6sign6s sauf V~\ Ics^tats-Un 

d^posant pour : LJ d6sign6s LJ les Etats-Unis d^ Am^rique Si^ seulement 


is d^Amdrique I 1 les Etats indiqu^s dans 
1 1 le cadre suppl6mentaire 


Nom et adresse : (hlom defamiUe suivi du prenom; pour une personne morale, designation 
oMcietle complete. L adresse doit comprendre le code postalet le nom du pays^ ^JITJiI 
I adresse indiquee dans ce cadre est I Etat ou le deposant a son domicile si aucun domicile 
n 'est indique ci-dessous.) 


Cette personne est : 

1 1 deposant seulement 

I [ dyposant et inventeur 

1 1 inventeur seulement 
cette case est cochee, 
ne pas remplir la suite.) 


Nationalile (nom de TEtat) : 


Domicile (nom de PEtat) : 


rette nereonne est 1 i tousles Etals | 1 tous les Elats dasign6s sauf 1 1 les Etats-Unis d'Am6rique 1 1 les ^Uts indiaues dans 

Ss^l^o ur : LJ d6sign6s • 1 | les Etals-Unis d»Am6rique I 1 seulement I 1 le cadre suppTdmcntaire 


Nom et adresse : (Nom defamiUe suivi du prenom: pour une personne morale, designation 
orient complete. L 'adresse doit comprendre le code postal ?/ le nom du pays, Lepays de 
I adresse indiquee dans ce cadre est I 'Etat oil le deposant a son domicile si aucun domicile 
n 'est indique ci'dessous.) 


Cette personne est : 

1 1 ddposant seulement 

1 1 ddposant et inventeur 

1 1 inventeur seulement 
(Si cette case est cochee. 
ne pas remplir la suite.) 


Nationality (nom de TEtat) : 


Domicile (nom de TElat) : 


rette nersonne est 1 1 tous les ttats | 1 tousjes Etats ddsign^s sauf | 1 les ^tats-Ui 

d^sSnt PO^^^^^^ 1—1 d^signds . LJ les Euts-Unis d'Amirique LJ seulement 


lis d'Amdrique | 1 les £tats indiguds dans 

1 1 Ic cadre suppr6mcntaire 


Nom et adresse : (Nom defamiUe suivi du prenom; pour une personne morale, designation 
omcielle com^^^ L 'adresse doit comprendre le code postal ?/ le nom du pays. U pays de 
Fadresse inT^^ dans ce cadre est I 'Etat ou le deposant a son domicile si aucun domicile 
n 'est indique ci-dessous.) 


Cette personne est : 

I 1 ddposant seulement 

I 1 deposant el inventeur 

1 1 inventeur seulement 
(Si cette case est cochee, 
ne pas remplir la suite.) 


Nationality (nom de PEtat) : 


Domicile (nom de Tfital) : 




j J D'autres ddposants ou inventcurs sont indiqu^s sur une autre feuille annexe. 



Formulaire PCT/RO/101 (feuille annexe) Guillet 1 998; rdimpression janvier 2000) Voir les notes relatives auformulaire de requete 



Feuille n° . - . 3 . 



Cadre n- V DESIGNATION D'ETATS 



it a la regie 4. 9. a) (cocker les cases appropriee\ 



au moins doit I 'etre) : 



Les designations suivanles sont faites confer 
Brevet regional 

Brevet ARIPO : GH Ghana, GM Gamble, KE Kenya, LS Lesotho, Malawi, SD Soudan, SL Sierra Leone, 

SZ Swaziland, TZ R6publique-Unie de Tanzanie, UG Ouganda, ZW Zimbabwe et lout autre Etat qui est un Etat contractant du 
Protocole de Harare et du PCT 

Brevet eurasien : AM Armenie, AZ Azerbaidjan, BY B6larus, KG Kirghizisian, KZ Kazakhstan, MDR^publiquede Moldova, 
RLf Federation de Russie, TJ Tadjikistan, TM Turkmenistan el tout autre Etat qui est un Etat contractant de la Convention sur 
. le brevet eurasien et du PCT 

E EP Brevet europeen : AT Autriche, BE Belgique, CH et LI Suisse et Liechtenstein, CY Chypre, DE Allemagne, 

^ DK Danemark, ES Espagne, Fl Finlande. FR France, GB Royaume-Uni, GR Gr6ce, lEJrlande, IT Italic, 
LU Luxembourg, MC Monaco, NL Pays-Bas, PT Portugal, SE Suede et tout autre Etat qui est un Etat contractant de la 
Convention sur le brevet europeen et du PCT 

□ OA Brevet OAPI : BF Burkina Faso, BJ B6nin, CF R^publique centrafricaine, CG Congo, CI Cote dMvoire, 
CM Cameroun, GA Gabon, GN Guinee, GW Guin6e-Bissau, ML Mali, MR Mauritanie, NE Niger, SN S^n^gal, 
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Procede de chargement d'applicati ns dans un systeme mbarque 
multi-application muni de ressources de traitement de donnees ^ 
systeme embarque correspondant, et procede d'execution d'une 
a pplication d'un systeme embarque correspondant 

5 La presente invention concerne un procede de chargement 

d'applications dans un systeme embarque multi-application muni de 
ressources de traitement de donnees, le systeme embarque correspondant, 
et le procede d'execution d'une application d'un systeme embarque 
correspondant. 

10 La presente invention concerne plus particuliere la realisation de 

pare-feu entre modules partageant le meme espace memoire dans des 
systemes embarques sur des objets portables multi-application utilisant un 
pseudocode intermediaire et une machine virtuelle associee. 

La technologie "Java" (marque deposee) introduite par la societe 

15 "Sun" est basee sur un langage de programmation oriente objet "Java" et 
une machine virtuelle associee. Cette technologie a ete developpee sur des 
stations ou PC (Personal Computer), appelees ci-apres plate-forme "Java" 
classique, possedant une puissance CPU et une memoire importante de 
I'ordre du mega byte ou megaoctet. 

20 Depuis quelques annees, les concepts de la technologie "Java" ont 

ete repris et adaptes pour fonctionner sur des systemes embarques dans 
des objets portables, par exemple au format de carte de credit ou 
micromodule SIM incorporant un microprocesseur et appelee communement 
carte a puce, ou encore de telephones portables GSM (Global System for 

25 Mobile Communication), cartes PCMCIA ou tous autres terminaux portables. 
Par la suite nous utiliserons le terme carte pour designer Tun quelconque de 
ces objets portables. La programmation des systemes embarques, jusqu'ici 
realisee en assembleur, est desormais possible dans un langage evolue 
comme '*Java", et permet de faciliter et d'accelerer le developpement 

30 d'applications clientes. 
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Ce nouveau type de plate-forme specifique aux systemes 
embarques d'un objet portable, appele ci-apres plate-forme specifique, 
constitue un sous-ensemble de la plate-forme classique. Les differences 
resultent du fait de I'environnement reduit des systemes embarques. De 

5 maniere classique, tel que represents a la figure 4a, une carte a puce (10) 
comprend un systeme d'entree et de sortie (11) relie au microprocesseur 
(14), une memoire volatile RAM (12) (Random Access Memory) une 
memoire non volatile constituee par une memoire morte ROM (13) (Read 
Only Memory) et une memoire non volatile programmable (15) constituee 

10 d'une flash RAM ou EEPROM (Electrically Erasable Programmable Read 
Only Memory). L'ensemble de ces elements est relie au microprocesseur par 
un BUS de liaison. A titre d'exemple, une carte a puce comprend dans le 
meilleurs des cas, en utilisant les nouveaux composants actuellement 
existants, une memoire ROM, une memoire EEPROM de 32 kilooctets ou 

15 kilo bytes, et une memoire RAM de 2 Kilo Bytes. 

Dans un systeme "Java" classique, une application est ecrite sur une 
station ou PC. Son code source est compile dans un pseudocode 
intermediaire, appele "Java Byte Code" ou byte code, qui est independant du 
code machine de la plate-forme utilisee. Uapplication est ensuite telechargee 

20 sur la plate-forme cible ou plate-forme "Java" classique. L'application 
chargee, constituee d'un ensemble de classes dites classes clients dont les 
methodes ont ete compilees dans le pseudocode, s'appuie sur les interfaces 
de programmation applicatives ou Interface pour la Programmation 
d'Application ou API (Application Programming Interface). Les interfaces de 

25 programmation applicatives permettent d'uniformiser I'interface utilisateur, de 
controler un editeur, un clavier ou une imprimante par exemple. La machine 
virtuelle d'une plate-forme classique comprend un verifieur de pseudocode, 
un chargeur dynamique de classe, un interpreteur de pseudocode qui 
permet la traduction en code machine et un gestionnaire de securite. 

30 La principale difference entre une machine virtuelle classique et une 

machine virtuelle d*un systeme embarque, appelee machine virtuelle 
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specifique, est due au fait que la machine virtuelle d*un systeme embarque 
est decomposee en deux parties separees. Suivant la figure 4b, la machine 
virtuelle comprend une partie (30) hors de la plate-forme specifique (40), 
appelee machine virtuelle hors plate-forme ("off-platform"), comprenant un 

5 convertisseur (32), et une partie (41) dans la carte constituant la plate-forme 
specifique (40), appelee machine virtuelle embarquee (41) ("on-platform") 
incluant I'lnterpreteur de pseudocode. 

Ainsi, dans le cas d'une plate-forme specifique, le programme source 
(21 ) de rapplication est ecrit, compile en pseudocode intermediaire par un 

10 compilateur (22), et verifie par un verifieur (31) de pseudocode intermediaire 
sur une station (20) classique, puis convert! par le convertisseur (32), place 
sur la meme station (20) ou une autre station. Apres un eventuel passage 
par un signeur (34), rapplication est ensuite telechargee sur la memoire 
volatile programmable electriquement et eventuellement effagable 

15 electriquement EEPROM (15) de I'objet portable ou plate-forme specifique 
(40). Ce chargement est effectue par un chargeur comportant une partie 
hors plate-forme appelee telechargeur (33) et une partie sur la plate-forme 
specifique appelee chargeur (42). Contrairement a ce qui existe sur une 
plate-forme classique pour une station, la machine virtuelle (41) d'une plate- 

20 forme specifique (40), placee en memoire ROM avec le systeme 
d'exploitation (48) (Operating System) ne peut comporter de verifieur de 
pseudocode intermediaire, celui-ci etant trop lourd pour etre stocke et/ou 
execute dans Tobjet portable. La plate-forme specifique (40) ne contient pas 
non plus de chargeur dynamique de classes. En effet, pour le domaine 

25 d'application de invention, sur la machine virtuelle (30) hors plate-forme, le 
verifieur (31) verifie que les classes compilees sont bien formees et verifie 
les violations de langage specifiques a la description de la plate-forme 
specifique. Le convertisseur (32) effectue le travail requis pour le 
chargement des classes et la resolution des references. Le convertisseur 

30 effectue la liaison statique des classes, il resout les references symboliques 
aux classes, methodes et attributs deja presents sur la carte. II repartit le 



stockage et cree les structures des donnees pour representer les classes, 
cree les methodes et attrlbuts statiques ou natifs et initialise les variables 
statiques. 

L'environnement d'execution de la plate-forme specifique (Runtime 
Environment ou RE) comprend la machine virtuelle embarquee ("on- 
platform") (41) se llmitant a un interpreteur, une plate-forme API et les 
methodes dites natives (43) ou encore statiques associees. La plate-forme 
API comprend les API (44) (Application Programming Interface) definissant 
un ensemble de classes, dites classes systeme (45), et les conventions 
d'appel par lesquelles une application accede a l'environnement d'execution 
(RE) et aux methodes statiques (43). Les methodes statiques (43) executent 
les services d'allocation de memoire, d'entree et sortie, et cryptographique 
de la carte. 

L'interpreteur de la machine virtuelle embarquee de la carte (41 )(on- 
platform), serf de support au langage "Java", et lit de fagon sequentielle le 
pseudocode intermediaire, instruction par instruction. Chaque instruction 
standard de ce pseudocode intermediaire est interpretee dans le langage du 
microprocesseur par l'interpreteur puts executee par le microprocesseur. En 
regie generate, les instructions standards du pseudocode intermediaire 
permettent de trailer des fonctions evoluees telle que le traitement 
arithmetique et la manipulations d'objets. La notion d'objet concerne les 
objets informatiques tels que listes, tableaux de donnees ou analogues. Les 
classes dites clients (46) des applications et les classes systemes (45) des 
API sont toutes chargees dans le meme espace memoire et sont ger§es par 
I'intermediaire d'une table de classe (47). 

La machine virtuelle (41) est egalement chargee de gerer les classes 
et objets et de faire respecter les separations ou pare-feu entre les 
applications afin de permettre un partage securise des donnees, appelees 
egalement attributs, variables ou champs (fields). 

Dans le cas d'un objet portable de type carte a puce, une application 
d'une plate-forme specifique peut etre activee directement par 
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renvironnement d'execution (RE) lorsqu'une APDU (Application Protocol 
Data Unit) de selection emise par un service ou terminal est regue par la 
carte. 

Afin de restreindre I'acces aux donnees entre les parties de code 
5 partageant le meme espace memoire, une des methodes classiques sur une 
plate-forme classique est basee sur la restriction explicite de visibilite 
declaree dans le code source. Suivant la figure 4c, les methodes (NM1, 
NM2), respectivement (NM3, NM4), et les attributs (NA1, NA2), 
respectivement (NA3, NA4) sont encapsules dans des classes (NCI3), 

10 respectivement (NCI2), qui elles-memes font partie de paquetages 
(Paquetage 1), respectivement (Paquetage n) regroupant chacun plusieurs 
classes. Une classe peut etre publique telle que (NCI1 ou NCI2) ou privee 
telle que (NCI3) par rapport a un paquetage, ce qui implique, dans le dernier 
cas, que seules les classes du meme paquetage peuvent acceder a cette 

15 classe. Les methodes (exemple NM2) et les donnees (exemple NA1) d'une 
classe (NCI3) peuvent etre privees par rapport a la classe {NM2, NA1), qui 
elle-meme est privee par rapport au paquetage (Paquetage 1), ou publiques 
par rapport au paquetage (par exemple NM1, NA2) ou a la classe (par 
exemple NM4, NA4). Cette restriction de la visibilite permet d'obtenir un 

20 acces flexible entre les differents ensembles de paquetages (Paquetage 1 , 
Paquetage n) stockes dans le meme espace nom, mais presente quelques 
inconvenients. La plate-forme classique ou specifique supporte ma! la notion 
de sous-paquetages. Les classes client d'une application de grande taille 
doivent etre reparties entre differents sous-paquetages qui representent 

25 uniquement pour la machine virtuelle des paquetages differents. Pour 
partager les ressources entre ces sous-paquetages, ces ressources sont 
necessairement declarees publiques, les rendant ainsi visibles de tout autre 
paquetage. II est ainsi difficile d'organiser de fagon claire le paquetage 
d'applications differentes pour des applications de grande taille et d'obtenir 

30 des pare-feu entre les applications. 



Dans le cas de la plate-forme classlque, sur une station, le respect 
de la confidentialite des ressources, telle que declaree dans les programmes 
sources, repose sur des verifications dynamiques. Pour effectuer ces 
verifications dynamiques, la machine virtuelle doit posseder toutes les 
informations concernant les declarations de restriction d'acces pour chaque 
classe, methode ou attribut, ce qui ne peut etre possible dans le cas de 
respace memoire disponible sur la machine virtuelle embarquee (onplatform) 
utilisant le pseudocode intermediaire ou byte code prelie de la machine 
virtuelle hors plate-forme (off platform). Dans le cas d'une plate-forme 
specif ique d'un objet portable, les restrictions d'acces peuvent se verifier 
statiquement lors de la compilation et peuvent etre verifiees a nouveau par le 
verifieur de la partie hors plate-forme. II est en effet suppose que ce qui est 
charge sur la plate-forme specifique de I'objet portable est correct, car 
aucune verification ne peut etre effectuee sur la plate-forme specifique du 
fait de la perte des informations lors de la phase de conversion. De plus il 
n'est pas garanti qu'un paquetage ne puisse pas etre etendu ou modifie par 
de nouvelles classes venant de sources etrangeres, ce qui peut detruire 
toute la securite bas§e sur Tutilisation de paquetages prives. 

Le deuxidme moyen procure par la machine virtuelle d'une plate- 
forme classique est la notion de separation des espaces nom. Avec le 
schema de liaison dynamique d'une plate-forme classique, les classes 
peuvent etre chargees, a partir de repertoires du systeme de fichier local, 
appele "ClassPath" prealablement declare comme constituant I'emplacement 
des classes systemes formant la plate-forme API standard, ou ^ partir 
d'autres repertoires du systeme de fichier local ou de serveurs 6loignes. Les 
classes client d'une application, exterieures au "ClassPath", doivent etre 
chargees par un chargeur de classe specifiquement programme. Cette 
caracteristique est particulierement utilisee pour le chargement des 
applications "Java" par des navigateurs habilites "Java". Ainsi, les 
applications venant de differentes sources, sont chargees par des chargeurs 
de classes differents. Pour chaque localisateur, communement appele URL 
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(Uniform Resource Locator), une instance specifique de classe "chargeur de 
classe d'application" est utilisee. Le nom externe d'une classe est 
I'assemblage <Nom Du Paquetage > + <Nom De La Classe>. Quand une 
classe est chargee, elle est stockee dans une table de classe interne, et une 
5 reference relative au chargeur de classe utilise pour charger cette classe est 
ajoutee en prefixe du nom de paquetage de la classe. Le nom de la classe 
est alors «Reference du Chargeur de Classe> + <Nom Du Paquetage> + 
<Nom De La CIasse». Ainsi des classes declarees comme appartenant au 
meme paquetage mais chargees par des chargeurs de classes differents ne 
10 sont pas pergues par la machine virtuelle comme appartenant au meme 
paquetage. 

Lors de la resolution d'une reference, la politique habituelle des 
chargeurs de classe est de rechercher d'abord dans les classes systeme et 
en cas d'echec, de rechercher parmi les fichiers de classe presents a 

15 I'emplacement ou le chargeur peut charger les classes. Selon ce principe de 
fonctionnement du chargeur, une application ne peut directement acceder 
aux classes clients d'une autre application chargee par un chargeur de 
classes different. Une application peut acceder a toutes les ressources 
publiques des classes publiques du ClassPath, mais les classes du 

20 ClassPath ne peuvent acceder directement aux classes d'une application 
bien qu'elles puissent faire reference a des instances de classes clients de 
Tapplication en les convertissant en un type public defini dans le "Classpath". 
Une application ne peut etendre ou modifier des paquetages de classes 
systeme du Classpath ou de toutes autres applications chargees par des 

25 chargeurs de classes differents. Uutilisation de la separation des espaces 
nom en inserant une reference du chargeur de classe dans le nom de la 
classe, ajoutee au typage complet fourni par le langage "Java", permet de 
procurer un pare-feu efficace entre les applications. Le mecanisme inne de 
separation de nom d'espace permet facilement le chargement de nouvelles 

30 applications. Les applications peuvent echanger des objets par I'entremise 
des classes specifiquement programmees a cette fin et localisees dans le 
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"Classpath". Une application peut utiliser un objet venant d'une autre 
application chargee par un chargeur de classe different, si cet objet peut etre 
change en un type public defini dans le "Classpath". 

Malheureusement ce mecanisme de separation de nom, base sur 
5 une machine virtuelle classique et son processus de liaison dynamique ne 
peut etre effectue sur une plate-forme specifique. La liaison dynamique ne 
peut etre effect uee par la machine virtuelle d'une plate forme specifique, 
celle-ci necessitant un espace memoire permettant le stockage de fichier de 
classe d'une plate-forme "Java" classique, presentant des references non 

10 resolues. Dans une plate-forme specifique, les classes systemes des API et 
les classes clients des applications ne sont pas isolees dans des espaces de 
nommage particuliers. 

L'objet de la presente invention est de proposer une solution 
procurant les avantages de la separation de nom dans le cadre de systemes 

15 embarques possedant une machine virtuelle en deux parties, le schema de 
liaison statique etant effectue par la partie hors plate-forme. 

Dans le contexte de systemes embarques, tels que par exemple les 
terminaux de paiement, multi-application, il est necessaire d'avoir des pare- 
feu performants entre les applications "Java" fournies par differentes 

20 sources, telles que differents systemes de paiement (Visa, Mastercard...). II 
peut etre utile de permettre une cooperation flexible entre les applications 
venant des differentes sources. Le systeme embarque doit aussi etre 
facilement mis a jour en telechargeant de nouvelles applications ou de 
nouveaux modules utilitaires ou encore des mises a jour sans perturber les 

25 applications deja chargees. 

Un premier but de I'invention est de proposer un precede de 
chargement permettant d'obtenir des pare-feu robustes entre les applications 
tout en autorisant une cooperation entre les applications et la possibilite de 
faire evoluer les applications ou de charger d'autres applications. 

30 Ce but est atteint par le fait que le precede de chargement 

d'applications sur un systeme embarque selon invention, comprenant un 
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environnement d'execution incluant une machine virtuelle comprenant un 
interpreteur de langage de type pseudocode intermediaire, des interfaces de 
programmation d'application (API), a partir d'une station sur laquelle le code 
source de I'application est ecrit. compile en pseudocode par un compilateur , 
5 verifie par un verificateur, convert! par un convertisseur et charge par un 
chargeur, se caracterise en ce que 

- la conversion comprend la realisation de la liaison statique d'une 
pluralite d'ensembles de paquetages destines a etre stockes dans le meme 
espace nom sur le systeme embarque, appeles modules, en attribuant un 

10 identificateur a chaque module (MID), et un numero de reference a chaque 
classe, a chaque methode et a chaque attribut encapsules dans les classes 
du module, 

- la reference a une methode ou un attribut, dans le pseudocode lie 
d*un module, etant codee sur trois multiplets constitues par un indicateur 

15 indiquant la reference a une classe interne ou externe au module, le numero 
de la classe et soit le numero de la methode soit le numero de I'attribut, 

- les modules charges sont un ou plusieurs modules d'interface de 
programmation d'application, appele Module API, comprenant des classes 
systeme ou des modules de services correspondant chacun a une 

20 application, une reference a une classe externe etant systematiquement 
interpretee par la machine virtuelle comme une reference a un module 
d'interface de programmation d^application. 

Selon une autre particularite, le chargement des modules sur le 
systeme embarque comprend la memorisation d'une part d'au moins un 

25 tableau de representation des modules, le numero associe, par le lieur 
compris entre 0 et n, a un module constituant I'index dudit module dans le 
tableau, et d'autre part d'une table memorisant I'association de I'index du 
tableau de representation a I'identificateur (MID) dudit module, ledit tableau 
et la table etant en memoire programmable non volatile, une reference 

30 externe a un module externe dans le pseudocode etant interpretee par 
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rinterpreteur de la machine virtuelle comme constituant un index d'acces au 
module equivalent a celui du tableau des modules. 

Selon une autre particularite, le chargement comprend la 
memorisation, pour chaque module, d'un tableau de representation de ses 
5 classes, comprenant une reference a I'index de son module et, pour chaque 
classe, un tableau de representation des attributs et des methodes. 

Selon une autre particularite, les modules sont references dans un 
tableau de modules unique, les classes systeme sont contenues dans un 
module API unique, toute reference a une classe externe dans le 
10 pseudocode differente de n sera interpretee par la machine virtuelle comme 
une reference audit module API. 

Selon une autre particularite, les classes etant declarees publiques, 
ou en paquetage prive, les attributs et methodes etant declares proteges, en 
paque.tage privee ou en classe privee, la numerotation des classes s'effectue 
15 suivant Tordre classes publiques puis classes en paquetages prives, la 
numerotation des attributs ou methodes est effectuee par le convertisseur 
suivant I'ordre attribut ou methode public, protege, en paquetage prive et en 
classe privee. 

Selon une autre particularite, les classes systeme sont contenues 
20 dans plusieurs modules API chargeables separement, le chargeur maintient 
dans la memoire non volatile programmable deux tableaux de representation 
des modules et deux tables d'association MID/IMi correspondantes, I'un pour 
les modules API et Tautre pour les modules non-API, le chargeur chargeant 
les modules dans I'un des deux tableaux selon la nature du module specifie 
25 dans rentete de celui-ci, toute reference externe d'un module du tableau de 
module etant interpretee comme une reference a Tindex du module API. 

Selon une autre particularite, la liaison statique d*un module est 
effectuee de telle sorte que la reference a une classe externe a un module 
non API dans le pseudocode intermediaire est un index dans un tableau de 
30 rentete du module, dont chaque entree est un identificateur (MID) d'un 
module API reference, le chargement dudit module sur la plate-forme cible 
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comprenant le remplacement de ladite reference par le numero de Tindex 
du module API obtenu a partir de ridentificateur (MID) de la table 
d'association des modules API, 

Un autre but de rinvention est de proposer un systeme embarque 
5 correspondant. 

Ce but est atteint par le fait que le systeme embarque selon 
rinvention, comprenant une machine virtuelle et une plate-forme API incluant 
des interfaces de programmation d'application, une memoire non volatile 
fixe, une memoire non volatile programmable ou modifiable, et une memoire 

10 vive. se caracterise en ce que la memoire non volatile programmable 
comprend au moins un module API comprenant des classes systeme et des 
modules de services, au moins un tableau de representation des modules, 
dans lequel les modules sont indexes et une table associant Tindex d'un 
module du tableau de representation a ridentificateur dudit module, chaque 

15 module comprenant un tableau de representation des classes, dans lequel 
les classes sont indexees et dans lequel chaque classe presente une 
reference a I'index de son module, chaque classe comprenant un tableau de 
representation des attributs et des methodes, dans lesquels les attributs et 
methodes sont indexes, la reference a une methode ou un attribut etant 

20 codee sur au moins trois multiplets correspondant a une reference a une 
classe interne ou externe au module, une reference externe au module 
constituant I'index du module API dans le tableau de module, un numero de 
classe correspondant a I'index de la classe dans la table de representation 
des classes du module, et un numero de methode ou d'attribut 

25 correspondant a Tindex de la methode ou de I'attribut dans le tableau de 
representation des methodes ou attributs de la classe du module. 

Selon une autre particularite, le systeme embarque comporte des 
moyens de comparaison du premier multiplet des trois multiplets de codage 
de reference a une methode ou a un attribut avec une valeur determinee n 

30 pour decider s'il s'agit d'une classe interne ou externe. 
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Selon une autre particularite, le systeme embarque comprend un 
module principal comprenant le programme principal du systeme. 

Selon une autre particularite, les classes sont indexees suivant 
rordre classes publiques puis classes en paquetages prives, et les attributs 
5 ou methodes suivant I'ordre attribut ou methode public, protege, en 
paquetage prive et en classe privee. 

Selon une autre particularite, la memoire non volatile programmable 
comprend plusieurs modules API comprenant des classes systeme, deux 
tableaux de representation des modules, Tun pour les modules API et Tautre 
10 pour les modules non-API et le module principal, et deux tables d'association 
MID/IMi correspondant chacune a un tableau de representation des 
modules., 

Selon une autre particularite, le systeme embarque comprend une 
classe gestionnaire d'acces "Access manager" d'un module API comprenant 

15 une methode permettant de creer une instance d'un module de service, par 
rintermediaire du module principal, ladite classe presentant une protection lui 
interdisant d'avoir plus d'une instance. 

Un autre but de Tinvention est de proposer un precede d'execution 
d'une application presente sur un systeme embarque multi-application. 

20 Ce but est atteint par le fait que le precede d'execution d'une 

application d'un systeme embarque multi-application, comprenant un 
environnement d'execution incluant une machine virtuelle comprenant un 
interpreteur de langage de type pseudocode intermediaire, et des interfaces 
de programmation d'applications (API), se caracterise en ce que, lors de 

25 rexecution du pseudocode intermediaire d'un module de service, 
correspondant a une application, referencee dans un tableau de module, la 
reference a une methode ou un attribut dans le pseudocode, codee sur au 
moins trois multiplets correspondant a une reference a une classe interne 
ou externe au module, un numero de classe et un numero de methode ou 

30 d'attribut, une reference externe au module est interpretee par la machine 



13 



virtuelle comme une reference a Tindex d'un module API du tableau du ou 
des modules API, 

Selon une autre particularite, sur reception d'une demande 
d'execution d'un module de service presentant un identificateur, 
5 I'environnement d'execution accede a la classe d'entree d*un module 
principal comprenant le programme principal du systeme, le module principal 
installe une instance d'une classe speciale "Access Manager", d'un module 
API, gerant Tacces a un module de service et utilise une methode de cette 
classe permettant de creer une instance de la classe d'entree du module de 

10 service demandee, par I'intermediaire d'une table d'association de 
ridentificateur a I'index du module dans un tableau dans lequel le module est 
reference, instance etant retournee par la methode au programme principal. 

D'autres particularites et avantages de la presente invention 
apparaTtront plus ctairement a la lecture de la description ci-apres faite en 

15 reference aux dessins annexes dans lesquels : 

- la figure 1 represente de fagon schematique les differents elements 
necessaires pour le chargement d'un objet portable selon un premier mode 
de realisation ; 

- la figure 2 represente de fagon schematique les differents elements 
20 necessaires pour le chargement d'un objet portable selon un deuxieme 

mode de realisation ; 

- la figure 3 represente la representation interne d'un module ; 

- la figure 4a represente le schema classique d'une carte a puce ; 

- la figure 4b represente le systeme necessaire a la constitution 
25 d'une machine virtuelle embarquee sur une carte a puce selon I'art anterieur; 

- la figure 4c represente la structure des classes d'une application. 
Le precede sera decrit, en liaison avec les figures 1 a 3, de maniere 

non limitative, dans le cas de la mise en oeuvre de I'invention dans un 
systeme embarque, par exemple de type specifique constitue par une carte 
30 a puce ou un objet portable similaire. La designation byte code ou 
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programme de type byte code recouvre tout pseudocode ou programme 
intermediaire. 

L'objet portable constitue par exemple une carte a puce et presente 
une structure similaire de celle ddcrite precedemment en reference aux 
figures 4a et 4b, et comprend notamment une memoire RAM, ROM et 
EEPROM. La plate-forme specifique (60) et une station classique (80) sont 
representees sur la figure 1. La plate-forme specifique (60) possede en 
ROM, un environnement d'execution (RE) comprenant des API (62) et une 
machine virtuelle (61) embarquee ("onplatform"). La plate-forme specifique 
(60) est representee sur la figure 1, comme comprenant I'ensemble des 
m^moires ROM et EEPROM. II est ^ noter que la plate-forme specifique (60) 
designe plus particulierement I'environnement d'execution (RE) et les 
elements presents en memoire EEPROM. L'objet portable possede en ROM 
un systeme d'exploitation (Operating System) (63). Les API (62), presentes 
en memoire ROM. constituent les API de base de la plate-forme API, 
charg^es avec la machine virtuelle embarquee pour le fonctionnement de 
celle-ci. 

La partie (90) hors objet portable de la machine virtuelle comprend 
un verifieur (91) de pseudocode intermediaire, un convertisseur (92) et 
6ventuellement un signeur (94). Le signeur delivre une signature pour valider 
le passage par le verifieur et le convertisseur. Cette signature sera verifi^e 
par l'objet portable au moment du chargement. Le chargement en EEPROM 
d'applications ou de nouvelles API pour completer les API de base s'effectue 
par un chargeur qui peut etre compost de deux parties, une partie hors objet 
portable pouvant etre installee dans la machine virtuelle hors objet portable 
(90), appelee telechargeur (93), et une partie sur la plate-forme specifique, 

appelee chargeur (68). 

Selon un premier mode de realisation, la plate-forme specifique (60) 
comprend deux modules speciaux, un module API (65) et un module 
principal (66). Les autres modules sont appeles modules de services (67). 
Chaque module correspond a un ensemble de paquetages qui sera stocke 
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dans le meme espace nom. La plate forme API designe les API de base (62) 
et I'ensemble des classes systeme qui definissent le module API (65) ou 
module de la plate-forme API. Le module principal comprend la classe 
principale definissant le programme principal. Chaque module, excepte le 
module API (65), possede une classe unique, particuliere, appelee "Entry 
Class", qui constitue le point d'acces au module. Pour le module principal, 
cette "Entry Class" est la classe principale (CP), celle qui contient une 
methode statique appelee "main". Pour les modules de services, c'est une 
classe avec seulement un constructeur sans parametres et implementant 
une interface publique speciale, appelee "service" definie dans la plate-forme 
API. Le chargement d'une application correspond au chargement d'un 
module de service. Chaque module regoit un identificateur specifique. Un tel 
identificateur, qui est appele MID, peut par exemple etre un nombre, une 
chaine de caracteres, ou un tableau. A titre d'exemple, I'identificateur est 
une chaine de caracteres. 

Quand ils sont charges dans la plate-forme, par des mecanismes de 
telechargement distincts de la machine virtuelle de la plate-forme specifique, 
les modules regoivent un nombre, compris entre 0 et n. Ainsi, selon cette 
convention, n+1 modules au plus peuvent etre presents sur la plate-forme 
specifique. Le telechargeur (93) de module avec le chargeur (68) maintient, 
lors du chargement de nouveaux modules de service, un tableau (TRM) (69) 
de representation des modules. Le numero associe a un module est I'index 
(IM) de ce module dans le tableau. Le chargeur (68) maintient egalement 
une table (70) associant Hndex (IM) a I'identificateur (MID) de chaque 
module. Le module API regoit systematiquement pour index IMo le numero 0, 
et le module principal pour index IMi le numero 1. L'entete (header) de 
chaque module comprend un indicateur permettant au chargeur de 
determiner la nature du module, "principal", modules "de service" ou module 
"API". 

Le chargeur (68) ne peut charger que les modules autorises a 
resider sur I'objet portable, c'est a dire uniquement les modules presentant 
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une signature connue de Tobjet portable. Le chargeur (68) comporte done 
des moyens de verifier la signature d'un module regu, de la comparer avec la 
signature connue de Tobjet portable et en cas de comparaison negative de 
bloquer le chargement. 
5 De maniere classique, tel que defini dans Tart anterieur cite 

precedemment, le programme source (81) d*une application est ecrit puis 
compile par un compilateur (82) et ensuite verifie par le verifieur (91). 

La liaison statique, realisee dans le convertisseur (92) par un 
composant dit lieur (linker) du convertisseur, va resoudre des references 
10 symboliques en attribuant 

- un numero (NCI) a chaque classe d'un module, 

- un numero (NM) pour chaque methode dans une classe et 

- un numero (NA) pour chaque attribut dans une classe. 

Chacun de ces numeros (NCI, NM, NA) est compris entre 0 et n et 

15 peut ainsi etre represents sur un byte ou multiplet. A titre d'exemple, chacun 
de ces nombres sera compris entre 0 et 255 (n=255). La reference a une 
methode ou un attribut d'une classe sera ainsi codee dans le pseudocode lie 
des methodes du module sur deux multiplets (bytes) ou octets. Le 
pseudocode contiendra ces deux multiplets < NCI> pour la classe et < NA> 

20 pour un attribut ou <NM> pour une methode. 

Suivant la figure 3, la representation interne d'un module API (65), 
d'un module principal (66) ou d'un module de service (67), contiendra un 
tableau (TRC) de representation de classes ; le numero (NCI) associe par le 
lieur, hors du systeme embarque, a chaque classe est I'index (ICi) de la 

25 representation de cette classe dans le tableau (TRC). Chaque classe 
presente egalement une reference a Tindex (IMi) de son module. De la 
meme maniere, la representation de chaque classe contient un tableau des 
representations de methodes (TRMe) et un tableau de representation des 
attributs (TRA) appartenant a la classe. Le numero (NM), associe par le lieur, 

30 hors du systeme embarque, a chaque methode est I'index (IMi), de la 
representation de cette methode dans le tableau (TRMe), et le numero (NA), 
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associe par le lieur, hors du systeme embarque, a chaque attribut est I'index 
(lAi), de la representation de cet attribut dans le tableau (TRA). 

A titre d'exemple, nous voulons qu*un module puisse referer 
uniquement a ses propres classes et aux classes systemes de la plate-forme 

5 API, les classes systeme correspondant aux classes du "ClassPath" d'une 
plate-forme classique. Selon I'invention, pour permettre la distinction entre 
une reference a une classe interne au module et la reference a une classe 
systeme (ou externe au module), un indicateur interne (II) ou externe (IE) est 
ajoute a la reference a une methode ou a un attribut. La reference resolue 

10 est alors codee sur trois multiplets : <IE/II> <NCI> < NM> ou <IE/II> <NCI> 
<NA> 

Selon une convention posee, pour la valeur n du premier multiplet 
<IE/II> la valeur 255 d'apres notre exemple, correspond a une reference 
interne <ll> au mpjduje et toute autre valeur pour le premier multiplet 

15 correspond a une reference externe <IE> au module. 

Le lieur du convertisseur (92) de la machine virtuelle hors objet 
portable (90), relie en premier le module API (65), qui ne possede pas de 
references externes <IE> dans son pseudocode, et produit une implantation 
ou agencement, correspondant a un plan de noms symboliques de ses 

20 classes et de leurs methodes et attributs. Lors de la mise en liaison des 
autres modules, cette implantation sera utilisee pour etablir les references 
externes a des classes systemes du module API (65). 

Suivant notre convention des multiplets (bytes) encodant les 
references, il peut y avoir au plus 256 (n+1) classes dans le module API et 

25 256 classes dans chaque module supplementaire. 

Lors de I'execution d'un module de service, quand la machine 
virtuelle (61) trouve une reference a une methode <NM> ou un attribut <NA> 
dans le pseudocode, en connaissant la classe <NCI> ou se trouve cette 
reference, elle peut retrouver directement Tindex <IMi> du module concerne, 

30 celui-ci correspondant a la reference externe (IE) ou interne (11). Toute 
reference externe <IE> dans le pseudo code d'un module de service sera 
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systematiquement interpretee par la machine virtuelle comme une reference 
au module API. Un module de service ou le module principal ne peut pas 
referer aux classes de tout autre module excepte celles du module API. Les 
classes systemes de ce module API ne peuvent pas referer aux classes d'un 
5 module de service ou du module principal. La reference interne a une classe 
d*un module, correspondant a la valeur n pour le premier multiplet, ne 
necessite aucune connaissance a priori de Tespace nom qui sera attribue au 
module. Le fait de ne pas definir a priori d'espace de nommage fixe lors de la 
phase de conversion permet d'accelerer la resolution des references et de 

10 determiner Tespace de nommage d'un module lors du chargement, 
posterieurement a la phase de conversion. La machine virtuelle, lors de 
I'interpretation d'une reference a un attribut ou a une methode dans le 
pseudocode, utilise les trois index <IE/II> <NCI> < NM> ou <IE/II> <NCI> 
<NA> en cascade. L'espace memoire du module etant determine, I'index 

15 <NCI> determine Tentree desiree dans le tableau des classes (TRM) du 
module, puis le dernier index < NM> ou <NA> donne Tentree desiree dans le 
tableau des methodes (TRMe) ou le tableau des attributs (TRA). 

Le module API comprend une classe speciale (64), appelee classe 
"gestionnaire d'acces" ou "Access Manager", qui comprend une methode 

20 native (getServicelnstance) dont le role est de rendre un objet instance de la 
classe d^entree du module de service demande, a partir de I'identificateur 
(MID) du module. Cette methode utilise la table (70) d'association MID/lmi 
pour connaTtre Tindex du module demande dans le tableau de module (69) 
puis cree une instance de la classe d*entree de ce module, instance qui est 

25 retournee par la methode. Selon invention la classe "Access Manager" (64) 
est protegee par construction par une methode consistant a interdire que 
cette classe ait plus d'une instance. Cette methode (getServicelnstance) 
appartient au programme principal contenu dans te module principal. Le 
module principal qui sera active en premier a utilisation de Tobjet portable 

30 cree une instance et une seule de la classe "Access Manager", ce qui lui 
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permet d'utiliser la methode getServicelnstance, mais interdit a tout autre 
service de creer une autre instance pour utiliser cette methode. 

En fonctionnement, de la meme fagon que sur une plate-forme 
classique, I'environnement d'execution (RE) accede a la classe d'entree (EC) 

5 du module principal et active sa methode d'entree (main). Le module 
principal, etant le premier active, precede a llnstallation d'une instance de la 
classe "Access manager" avant que tout autre service le fasse, puisque pour 
activer d'autres services, le module principal doit deja posseder une telle 
instance de la classe acces. 

10 Ce simple dispositif permet de reproduire i'effet de protection lie au 

concept d'espace de nommage d'une plate-forme classique. Le simple fait 
de charger un module de service dans le tableau des modules et que la 
presence dans le pseudocode de toutes reference externe soit interpretee 
par la machine virtuelle comme une reference au module API, rend ce 

15 module completement inaccessible directement par les autres modules, 
creant ainsi un pare-feu total. 

Ce premier mode de realisation permet d'apporter les avantages de 
pare-feu procure par la separation des espaces nom dans le contexte d'une 
machine virtuelle en deux parties. Toutefois ce mode de realisation se revele 

20 peu flexible et presente deux inconvenients. 

Premierement, il empeche toute modification ou extension des 
classes systemes avec des modules deja prelies. Une architecture "Java" 
classique permet de modifier et d'etendre les classes de la plate-forme API 
sans avoir d'impact sur les classes deja compilees de modules 

25 supplementaires. Mais dans le mode de realisation decrit precedemment, 
toute modification des classes systeme, meme invisible pour des modules 
etrangers, modifierait Tagencement de la plate-forme API et necessiterait de 
modifier le pseudocode prelie de chaque module deja lie avec une version 
anterieure de I'agencement et en consequence Tinterpreteur. 

30 Deuxiemement, les modules prelies sent supposes etre portables 

entre les differentes plates-formes ou terminaux embarques, ce qui impose 
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que chacune de ces plates-formes doit avoir le meme agencement que la 
plate-forme API, ce qui interdit I'utilisation de toute extension proprietaire. 

Afin de remedier partiellement a ces inconvenients, une variante du 
premier mode de realisation, consiste a imposer que, dans la numerotation 
de I'implantation, les classes publiques viennent en premier avant les 
classes en paquetage prive. De plus, les methodes publiques ou les attributs 
publics viennent avant ceux qui sont proteges et ceux qui sont en 
paquetages prives et en classes privees. Ceci permet d'ajouter librement de 
nouvelles classes publiques dans le module API (65). 

La figure 2 represente un deuxieme mode de realisation permettant 
revolution de la plate-forme API. La plate-forme API est constituee de 
plusieurs modules API (100) pouvant etre charges separement, au lieu d'etre 
constituee d'un module API unique. 

Dans ce mode de realisation, le telechargeur (93) et la machine 
virtuelle partagent deux tableaux de modules et deux tables d'association 
MID/index au lieu d'un de chaque, un tableau (101) et une table 
d'association (102) pour les modules API et un tableau (103) et une table 
d'association (104) pour les modules non-API, correspondant au module de 
service (67) et au module principal (66). 

Chaque module presente dans son entete un indicateur indiquant sa 
nature "Service" ou "API" permettant au chargeur de charger le module dans 
le tableau (101) de modules API ou dans le tableau (103) de modules non- 
API. Get indicateur est place dans l'ent§te du module lors de la phase de 
compilation par le convertisseur. 

Le pare-feu constitue par la separation de I'espace nom est present 
uniquement entre les modules non-API. Toute reference externe a un 
module de service sera interpretee par I'interpreteur de la machine virtuelle 
embarquee comme un index du tableau du module API. 

Les modules non-API seront numerot§s de 0 jusqu'a 255 au plus, 
dans I'exemple ou n=255. 0 est par exemple I'index du module principal (66). 
Les modules API (100) seront numerotes de 0 a 254 au plus, 0 etant par 



exemple Tindex d'un module dit API primaire, qui contient toutes les 
methodes natives. Conformement a la convention decrite precedemment, 
ceci permet au plus, 255 (n) modules difterents dans la plate-forme API. La 
reference a une methode ou attribut dans le pseudocode est : 

5 « IE/II> <NCI > < NM/NA» 

La valeur 255 (n) pour le premier multiplet (byte) indiquera, comme 
dans le premier mode de realisation, une reference interne au module. 
Chaque valeur differente de 255 indiquera une reference externe a un 
module specifique (100) du tableau de module API de la plate-forme API. 

10 Apres la realisation de la liaison par le lieur (92) hors plate-forme, le 

pseudocode d'un module comporte une entete presentant un tableau de 
modules references utilise pour Her le module courant. Ce tableau de 
modules references comprend au plus 255 entrees, chaque entree 
correspondant a ndentificateur (MID) d'un module API (100). Le premier 

15 multiplet (byte) d'une reference externe dans le pseudocode sera alors un 
index dans ce tableau. Lors du chargement sur la plate-forme d'un module 
non API (67, 66), les numeros d'index associes a des modules API (100) 
seront connus et ainsi chaque premier octet d'une reference externe sera 
remplace par le numero d'index associe au module API refere en utilisant la 

20 table (102) d*association MID/IMi des modules API (100). Ce remplacement 
est la seule operation de liaison realisee sur la plate-forme specifique, par le 
chargeur (68), la table (102) d'association MID/IMi etant utilisee uniquement 
pour realiser cette operation de liaison. 

A titre d'exemple, supposons que dans le pseudocode d'un module 

25 de service "TEST", nous avons la reference a un numero de methode 5 du 
numero de classe 7 d'un module API dont I'identificateur (MID) est "FOO". 
Supposons de plus que "FOO" est I'identificateur du quatrieme module API 
externe trouve reference dans le module de service "TEST". La reference 
dans le pseudocode est alors constituee par les trois valeurs suivantes : 3, 7, 

30 5. 
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Le numero 3 correspond au quatrieme index dans le tableau de 
modules references present dans I'entete du module, venant en tete du 
pseudocode, la valeur de cette entree etant I'identificateur (MID) "FOO". 
Supposons que lors du chargement du module API "FOO, I'index Interne 34 

5 lui ait ete attribue sur la plate-forme cible dans la table d'association (102) 
des modules API. Alors, le chargeur (68), ^ I'aide de la table d'association 
(1 02) modifie la reference dans le pseudocode du module de service "TEST" 
pour devenir : 34, 7, 5. 

Lors de I'execution du pseudocode d'un module, une reference 

10 externe au module est systematiquement interpretee par la machine virtuelle 
comme une entree dans la table de module API. Les modules du tableau de 
module non API restent invisibles les uns des autres ainsi que par rapport 
aux modules API. Ce simple dispositif permet de reproduire I'effet de 
protection lie au concept d'espace de nommage d'une plate-forme classique. 

15 Le simple fait de charger un module dans le tableau de module non API le 
rend completement inaccessible directement par les autres modules, creant 
ainsi un pare-feu total. 

Le tableau (101) de modules API comprend un module specifique 
(105), appele module "API Access" qui comprend une methode native 

20 (getServicelnstance) dans une classe "gestionnaire d'acces" ou "Access 
Manager" dont le role est de rendre un objet instance de la classe d'entree 
du module de service demande. Cette methode utilise la table (104) 
d'association MID/IMi pour connaTtre I'index du module de service demande 
dans le tableau (103) de modules non-API puis cree une instance de la 

25 classe d'entree de ce module qui est retournee par la methode au 
programme principal. La politique de securite preconisee est de faire de la 
classe "Access Manager" une classe protegee dont le constructeur et les 
methodes sont declares proteges. De plus, le module "API Access" (105) 
comprend une protection consistant a interdire que la classe "Access 

30 Manager" ait plus d'une instance. Cette methode est resen/ee au programme 
principal contenu dans le module principal (66). Le module principal qui est 
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active en premier cree une instance du module Access manager, ce qui lui 
permet d'utiliser la methode getServicelnstance, mais interdit a tout autre 
service de creer une autre instance pour utiliser cette methode. Ainsi le 
module principal pourra creer des instances de services. 

Plusieurs methodes peuvent etre utilisees pour obtenir cette 
protection consistant a interdire que la classe "Access manager" n'ait qu'une 
seule instance. Le constructeur de la classe peut par exemple bloquer la 
demande de creation d'instance lorsqu'il en existe deja une et lance une 
exception de securite. En fonctionnement, I'environnement d'execution (RE) 
accede a la classe d'entree du module principal (66) et active sa methode 
d'entree (main). Le module principal etant le premier active, precede a 
I'installation d'une instance de la classe "Access Manager" du module 
Access avant que tout autre service le fasse. 

Afin de permettre a un module de service d'activer un autre module 
de service, cette politique strict© de securite peut etre modifiee en ajoutant a 
la classe "Access Manager" du module API Access (105) des classes 
publiques permettant a tout module d'y faire des requetes. Ces requetes 
seront traitees et controlees par I'unique instance creee par le module 
principal. Ces classes publiques comprennent notamment une methode 
statique permettant d'obtenir I'unique instance. Un module ayant acces a 
I'objet instance de la classe "Access Manager" pourra activer un autre 
module de service et I'utiliser, mais il ne pourra pas referencer directement 
ses classes, ses methodes ou ses attributs sans etre repere par la machine 
virtuelle, etant donne que toute reference externe dans le pseudocode est 
une reference interne au module ou une reference externe a un module API. 

Pour une realisation simple de cette solution, il est n^cessaire de ne 
pas avoir de references circulaires parmi les modules API. En consequence, 
la fermeture transitive de la relation "refere ^("refers to") doit etre un ordre 
strict partiel sur un jeu de modules. II est ainsi possible de concevoir dans le 
lieur du convertisseur (92) une strategie simple pour lier et produire 
I'agencement des modules API en traitant en premier les elements 



minimums non encore lies. II est possible de suivre la meme strategie basee 
sur un ordre partiel pour le telechargement des modules API, de telle sorte 
que lors du telechargement d'un module M, tous les modules auquel il se 
refere aient deja ete telecharges et qu*un numero leur aient ete assigne. 

5 ^assignation de I'index interne sur la plate-forme cible se fait par le chargeur 
(68) de module en assignant Tindex n-1 a TAPI d'ordre n. Un module API ne 
peut referer a un autre API module d'index superieur. 

^utilisation de ce systeme de double tableau de modules (101, 103) 
et de table d'association (102, 104), permet de remplacer facilement un 

10 module API unique par plusieurs modules API chargeables separement. Le 
remplacement d'un module API unique par plusieurs modules API permet 
d'etendre la plate-forme API avec de nouveau modules, sans modifier 
rassemblage des modules deja charges, sans changer la securite offerte par 
les^pare-feu. Bien entendu, ces deux mo_d_es de realisation ne sont pas 

15 compatibles ; les modules doivent etre prelies specifiquement pour I'un ou 
rautre des modes de realisation, le pseudocode relatif a un des modes de 
realisation n'etant pas portable sur une plate-forme implementant I'autre 
mode de realisation. De plus, I'interpreteur de la machine virtuelle differe 
d'un mode de realisation a I'autre. Dans le premier mode de realisation, la 

20 machine virtuelle ne manipule qu'un seul tableau et une table d'association : 
le premier multiplet d'une reference sera interprete par la machine virtuelle 
comme une reference interne pour toute valeur egale a n et comme une 
reference externe a I'unique module API pour toute valeur differente de n. 
Dans le second mode de realisation, la machine virtuelle manipule deux 

25 tableaux et deux tables d'association : le premier multiplet d'une reference 
dans le pseudocode sera interprete par la machine virtuelle comme une 
reference interne au module pour toute valeur egale a n et toute valeur 
differente de n sera prise directement comme index dans le tableau de 
module API. Dans les deux modes de realisation I'interpreteur de la machine 

30 virtuelle comprend des moyens de comparaison du premier multiplet des 
trois multiplets de codage d'une reference a une methode ou a un attribut 
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avec une valeur determin^e n pour decider s'il s'agit d'une classe interne ou 
externe au module. La numerotation des modules API peut etre determinee 
au moment du chargement pour fixer definitivement et de maniere tres 
simple les references externes dans le pseudocode. 

5 Les memos mecanismes sont utilises pour manier les deux types de 

modules, bien que la fagon dont ils sont utilises et la securite procuree soient 
tout a fait differentes. Tout module peut acceder librement aux modules API 
puisque leurs classes sont des classes systeme. L'utilisation de I'approche 
modulaire est utilisee avec les modules services pour procurer un pare-feu 

10 rigoureux pour proteger ces modules de tout acces direct. 

Le precede selon I'invention peut etre r6alis6 sur tous types d'objet 
portable presentant de faibles ressources, tel que par exemple, 16 Ko de 
memoire ROM, 8ko de memoire EEPROM et 256 k de memoire RAM. 

D'autres modifications a la portee de I'homme de metier font 

15 egalement partie de I'esprit de I'invention. 



REVENDICATIONS 

1 . Procede de chargement d'applications sur un systeme embarque 
comprenant un environnement d'execution incluant une machine virtuelle 

5 comprenant un interpreteur de langage de type pseudocode intermediaire, 
des interfaces de programmation d'application (API), a partir d'une station 
sur laquelle le code source de rapplication est ecrit, compile en pseudocode 
par un compilateur (82), verifie par un verificateur (91), converti par un 
convertisseur (92), et charge par un chargeur (93, 68), caracterise en ce que 

10 - la conversion comprend la realisation de la liaison statique d'une 

pluralite d'ensembles de paquetages destines a etre stockes dans le meme 
espace nom sur le systeme embarque, appeles modules, en attribuant un 
identificateur a chaque module (MID), et un numero de reference a chaque 
classe (NCI), a chaque methode (NM) et a chaque attribut (NA) encapsules 

15 dans les classes du module, 

- la reference a une methode ou un attribut. dans le pseudocode lie 
d'un module, etant codee sur trois multiplets constitues par un indicateur 
indiquant la reference a une classe interne (II) ou externe (IE) au module, le 
numero de la classe (NCI) et soit le numero de la methode (NM) soit le 

20 numero de I'attribut (NA), 

- les modules sont un ou plusieurs modules d'interface de 
programmation d'application comprenant des classes systeme ou des 
modules de services correspondant chacun a une application, une reference 
(IE) a une classe externe etant systematiquement interpretee par la machine 

25 virtuelle comme une reference a un module d'interface de programmation 
d'application. 

2. Procede de chargement d'applications sur un systeme embarque 
selon la revendication 1 , caracterise en ce que le chargement des modules 
sur le systeme embarque comprend la memorisation d'une part d'au moins 

30 un tableau (69, 101, 103) de representation des modules, le numero (IMi) 
associe, par le lieur compris entre 0 et n, a un module constituant Tindex 
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dudit module dans le tableau, et d'autre part d'une table (70, 102, 104) 
memorisant rassociation de I'index du tableau de representation a 
ridentificateur (MID) dudit module, ledit tableau et la table etant en memoire 
programmable non volatile, une reference externe (IE) a un module externe 
5 dans le pseudocode etant interpretee par rinterpreteur de la machine 
virtuelle comme constituant un index d'acces au module equivalent a celui 
du tableau des modules. 

3. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 2, caracterise en ce que le chargement comprend la 

10 memorisation, pour chaque module, d*un tableau de representation (TRC) de 
ses classes, comprenant une reference a Tindex de son module et, pour 
chaque classe, un tableau de representation (TRA) des attributs et des 
methodes (TRMe). 

4. Precede de chargement d'applications dans un systeme 
15 embarque selon la revendication 2, caracterise en ce que les modules sont 

references dans un tableau de modules unique, les classes systeme sont 
contenues dans un module API unique, toute reference a une classe externe 
dans le pseudocode differente de n sera interpretee par la machine virtuelle 
comme une reference audit module APL 

20 5. Precede de chargement d'applications dans un systeme 

embarque selon la revendication 4, caracterise en ce que les classes etant 
declarees publiques, ou en paquetage prive, les attributs et methodes etant 
declares proteges, en paquetage privee ou en classe privee, la numerotation 
des classes s'effectue suivant Tordre classes publiques puis classes en 

25 paquetages prives, la numerotation des attributs ou methodes est effectuee 
par le convertisseur (92) suivant I'ordre attribut ou methode public, protege, 
en paquetage prive et en classe privee. 

6. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 2, caracterise en ce que les classes systeme sont 

30 contenues dans plusieurs modules API chargeables separement, le 
chargeur (68) maintient dans la memoire non volatile programmable deux 
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tableaux de representation des modules et deux tables d'association MID/lmi 
correspondantes, I'un pour les modules API et Tautre pour les modules non- 
API, le chargeur chargeant les modules dans Tun des deux tableaux selon la 
nature du module specifie dans Tentete de celui-ci, toute reference externe 
5' d'un module du tableau ^e module etant interpretee comme une reference a 
I'index du module API. 

7. Precede de chargement d'applications sur un systeme embarque 
selon la revendication 6, caracterise en ce que la liaison statique d'un 
module est effectuee de telle sorte que la reference a une classe externe a 

10 un module non API dans le pseudocode intermediaire est un index dans un 
tableau de I'entete du module, dont chaque entree est un identificateur (MID) 
d'un module API reference, le chargement dudit module sur la plate-forme 
cible comprenant le remplacement de ladite reference par le numero de 
rindex du module API obtenu a partir de I'identificateur (MID) de la table 

15 d'association MID/IMi des modules API. 

8. Systeme embarque comprenant une machine virtuelle et une 
plate-forme API incluant des interfaces de programmation d'application, une 
memoire non volatile fixe, une memoire non volatile programmable ou 
modifiable, et une memoire vive, caracterise en ce que la memoire non 

20 volatile programmable comprend au moins un module API comprenant des 
classes systeme et des modules de services, au moins un tableau de 
representation des modules (TRM), dans lequel les modules sont indexes et 
une table (70, 104) associant Tindex (IM) d'un module du tableau de 
representation a I'identificateur (MID) dudit module, chaque module 

25 comprenant un tableau de representation des classes (TRC), dans lequel les 
classes sont indexees et dans lequel chaque classe presente une reference 
a I'index (IM) de son module, chaque classe comprenant un tableau de 
repreisentation des attributs (TRA) et des methodes (TRMe), dans lesquels 
les attributs et methodes sont indexes, la reference a une methode ou un 

30 attribut etant codee sur au moins trois multiplets (bytes) correspondant a une 
reference a une classe interne (II) ou externe (IE) au module, une reference 
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externe au module constituant I'index du module API dans le tableau de 
module, un numero de classe (NCI) correspondant a I'index de la classe 
dans la table de representation des classes du module, et un numero de 
methode (NM) ou d*attribut (NA) correspondant a I'index de la methode ou 
5 de I'attribut dans le tableau de representation des methodes ou attributs de 
la classe du module. 

9. Systeme embarque selon la revendication 8, caracterise en ce 
qu'il comporte des moyens de comparaison du premier multiplet des trois 
multiplets de codage de reference a une methode ou a un attribut avec une 

10 valeur determinee n pour decider s'il s'agit d'une classe interne ou externe. 

10. Systeme embarque selon la revendication 8, caracterise en ce 
qu'il comprend un module principal comprenant le programme principal du 
systeme. 

1 1 . Systeme embarque selon la revendication 8, caracterise en ce 
15 que les classes sont indexees suivant Tordre classes publiques puis classes 

en paquetages prives, et les attributs ou methodes suivant Tordre attribut ou 
methode public, protege, en paquetage prive et en classe privee. 

12. Systeme embarque selon la revendication 11, caracterise en ce 
que la memoire non volatile programmable comprend plusieurs modules API 

20 comprenant des classes systeme, deux tableaux de representation (101, 
103) des modules, Tun pour les modules API et I'autre pour les modules non- 
API, et le module principal, et deux tables (102, 104) d'association MID/IMi 
correspondant chacune a un tableau de representation des modules. 

13. Systeme embarque selon la revendication 10, caracterise en ce 
25 qu'il comprend une classe gestionnaire d'acces "Access manager" d'un 

module API (105) comprenant une methode permettant de creer une 
instance d'un module de service, par I'intermediaire du module principal, 
ladite classe presentant une protection lui interdisant d'avoir plus d'une 
instance. 

30 14. Precede d'execution d'une application d'un systeme embarque 

multi-application, comprenant un environnement d'execution incluant une 
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machine virtuelle comprenant un interpreteur de langage de type 
pseudocode intermediaire, et des interfaces de programmation d'application 
(API), caracterise en ce que, lors de Texecution du pseudocode intermediaire 
d'un module de service, correspondant a une application, referencee dans 
5 un tableau de module, la reference a une methode ou un attribut dans le 
pseudocode, codee sur au moins trois multiplets (bytes) correspondant a 
une reference a une classe interne (II) ou externe (IE) au module, un numero 
de classe (NCI) et un numero de methode (NM) ou d'attribut (NA), une 
reference externe au module est interpretee par la machine virtuelle comme 

10 une reference a I'index d'un module API du tableau du ou des modules API . 

15. Precede d'execution d'une application d'un systeme embarque 
multi-application selon la revendication 14, caracterise en ce que, sur 
reception d'une demande d'execution d'un module de service presentant un 
identificateur (MID), Tenvironnement d'execution accede a la classe d'entree 

15 d'un module principal comprenant le programme principal du systeme, le 
module principal installe une instance d'une classe speciale "Access 
Manager" d'un module API, gerant I'acces a un module de service, et utilise 
une methode de cette classe permettant de creer une instance de la classe 
d'entree du module de service demandee, par I'intermediaire d'une table 

20 d'association de I'identificateur a Tindex du module dans un tableau dans 
lequel le module est reference, I'instance etant retournee par la methode au 
programme principal. 
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ABREGE 

Precede de chargement d'applications dans un systeme embarque 
multi-application muni de ressources de traitement de donnees , 
5 systeme embarque correspondant, et precede d'execution d'une 

a pplication d'un systeme embarque correspondant 

La presente invention concerne un procede de chargement d'applications 
dans un systeme embarque multi-application, le systeme embarque 

10 correspondant, et le procede d'execution d'une application du systeme 
embarque. Le procede de chargement d'applications sur un systeme 
embarque comprenant un environnement d'execution incluant une machine 
virtuelle comprenant un interpreteur de langage de type pseudocode 
intermediaire, des interfaces de programmation d'application (API), a parti r 

15 d'une station sur laquetle le code source de I'application est ecrit, compile en 
pseudocode, verifie et converti, se caracterise en ce que la conversion 
comprend la realisation de la liaison statique d'une pluralite d'ensemble de 
paquetages destines a etre stockes dans le meme espace nom sur le 
systeme embarque, appeles modules, et constituant un module d'interface 

20 de programmation d'application ou un module de service correspondant a 
une application, et consiste a attribuer un identificateur a chaque module 
(MID), et un numero de reference a chaque classe (NCI), a chaque methode 
(NM) et a chaque attribut (NA). La reference a une methode ou un attribut, 
dans le pseudocode lie d'un module est codee sur trois multiplets constitues 

25 par un indicateur indiquant la reference a une classe interne (II) ou externe 
(IE) au module, le numero de la classe (NCI) et soit le numero de la methode 
(NM) soit le numero de Tattribut (NA), une reference (IE) a une classe 
externe etant systematiquement interpretee par la machine virtuelle comme 
une reference a un module d'interface de programmation d'application. 
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